1. Technical Field
This disclosure relates to processors, and more specifically to interrupt processing (for example, in power-managed servers).
2. Description of the Related Art
Power management is increasingly important in the high-performance server industry. Customers prefer to minimize the total cost of ownership of such servers, which includes electricity costs and facility cooling costs.
Many servers include a number of multi-core, multi-threaded processors. For example, a server might include 8 processors, each with 8 cores, each supporting 8 threads (for a total of 512 threads). Often, processor workloads vary depending on performance requirements, the time of day, etc. At times, all threads on all cores on all processors may be busy; at other times, only a few cores have busy threads. Cores that are not busy are often selectively directed to enter a lower power state to save power. For example, cores may be powered down may have their clocks disabled. Turning off power to a core may entail a longer re-initialization sequence to bring the core back to a powered state, but saves more power than turning off the clock to a core. Turning off the clock to a core allows the core to be disabled and re-enabled more quickly, but saves less power. Typically, several operating system instances share the same server hardware and each operating system may execute various software applications. Power management software often monitors utilization of processor cores and notifies software applications via the operating system instances when it decides to dynamically disable or enable a core (e.g., by modifying power state, a clock, etc.).
Interrupts generated by hardware input/output (I/O) devices and interrupts generated by software are typically directed through configuration registers or tables to a specific thread and/or a specific core of a specific processor. Interrupts are typically asynchronous events, so an interrupt source (or initiator) may receive no specific acknowledgment that an interrupt is received. Therefore, if an interrupt is sent to a core that is powered down or has its clock disabled, the interrupt may be eventually lost. Further, the source of the interrupt (e.g., a software application executing on a particular core or peripheral device) may not know that the loss or drop occurred. The consequences of dropped interrupts can be serious, including reduced application performance if devices or software re-issue dropped interrupts. In some cases, dropped interrupts may even cause applications to fail.
Software-based solutions are one approach to dropped interrupts. Power-management software may communicate with application software (i.e., the software that generates the interrupt) to attempt to ensure that an interrupting processing element does not send an interrupt to a processing element once the processing element has been powered down. Power-management software may similarly communicate with peripheral devices. But, software-based solutions may not be satisfactory for a number of reasons.